Ethernet services are increasingly widely deployed, especially in metro networks. The Metro Ethernet Forum defines the basic Ethernet services to be supported by an Ethernet network, such as E-Line, E-Tree and E-LAN (MEF 6.1: “Metro Ethernet Services Definitions Phase 2” (April 2008)). E-Line is a point-to-point service; E-Tree is essentially a point-to-multipoint service; and E-LAN is a multipoint-to-multipoint service. E-Tree can be implemented by establishing a multicast transmission, and embedding users' data frames corresponding to a service (“service frames”) in multicast frames in a metro region. E-LAN might be implemented as a set of multicast trees.
Operators of networks need to take measurements in order to monitor the performance of those networks. Operators typically prefer to implement passive measurements, which rely on counters: the service parameters are determined based on these counters. The counters are typically carried in Operation Administration Maintenance (OAM) frames instead of service frames, although OAM frames should travel the same path as service frames. This means that the users' service frames are not modified for measurement purposes.
Service parameter measurement is a key issue both for operators and their subscribers, in order to verify their agreements and to check whether the requirements for specific services are met. There are mature measurement methods defined for point-to-point services, which are typically established by unicast connections, defined for example in ITU-T Rec. Y.1731 (February 2008): “OAM functions and mechanisms for Ethernet based networks”. Frame loss measurement methods are also defined in the same document. However, accurate frame loss measurement methods are not yet defined for multicast services, though the corresponding parameters have been recently defined in ITU-T Rec. Y.1563 (January 2009): “Ethernet frame transfer and availability performance”.
Provider and customer networks are typically separated by full header encapsulation at the edge of the provider network. This is also essential for the proper operation of loss measurement because, if this were not the case, customer frames entering the provider network at different edge nodes would not be distinguishable. One possibility to implement encapsulation in an Ethernet network is described in IEEE 802.1ah: “Provider Backbone Bridges” (August 2008). Note, that instead of full header encapsulation, other methods could be applied, such as source address tables at the measurement point for IEEE 802.1ad.
FIG. 1 is a schematic illustration of a provider network 101, which uses this approach. The provider network 101 is bordered by Backbone Edge Bridges (BEB) 102, 103, 104, 105, 106, 107, and includes Backbone Core Bridges (BCB) 108, 109, 110 inside the network.
Measurements are invoked by Maintenance End Points (MEP), which reside in edge nodes of the network. In the example shown in FIG. 1, these edge nodes are the BEBs 102-107. Essentially, MEPs exchange OAM frames for the measurement of service parameters. Intermediate nodes such as BCBs 108, 109, 110 may include Maintenance Intermediate Points (MIP).
Point-to-multipoint services can be efficiently implemented in Ethernet networks by the usage of multicast frames. In a basic Ethernet network where there is no support for multicast frame forwarding, all multicast frames are sent to all bridges in the network, as the proper forwarding is not set for the multicast destination addresses. This operation is illustrated in FIG. 2, which shows the network 101 of FIG. 1.
As shown in FIG. 2, BEB1 102 is a source node of a multicast service; BEB2 103 and BEB3 104 are the recipients registered for the service. However, as FIG. 2 shows, every node receives the frames 201 corresponding to the multicast service if no protocol for multicast support is running in the network. This means that the service frames are received by the registered nodes BEB2 103 and BEB3 104, but also by the unregistered end nodes such as BEB4 105, BEB5 106 and BEB6 107. The unregistered end nodes BEB4 105, BEB5 106 and BEB6 107 therefore need to drop the frames they are not registered to receive. It will be appreciated the diagram is illustrative only, and there may be more than one subscription simultaneously active per destination. There may also be more than one source for any given multicast destination address.
There are two protocols specified for supporting multicast forwarding in an Ethernet network by directing multicast frames only towards addresses registered for the multicast service: the Multiple Registration Protocol (MMRP) (defined in IEEE 802.1ak) and Internet Group Management Protocol (IGMP) snooping (defined in IETF RFC 4541). If either of them is applied in the network then multicast frames are forwarded as illustrated in FIG. 3: the frames 301 corresponding to the service whose source is BEB1 102 are only forwarded to BEB2 103 and BEB3 104, which are the registered recipients for that service.
Any method that is applied for accurate loss measurement corresponding to a multicast service will depend on the forwarding scheme applied in the network, i.e. whether or not MMRP (or IGMP snooping) is applied.
There are currently no suitable multicast service frame loss measurement methods. It is desirable for exact loss measurement of multicast frames to be done on a three-tuple relation of the sender and multicast destination address and the receiving node.
Previous measurement systems such as that described in ITU-T Rec. Y.1731 (February 2008): “OAM functions and mechanisms for Ethernet based networks” have focussed only on the measurement of point-to-point performance parameters, leaving multipoint for further study. If such measurement systems are to be adapted to measure services in multipoint systems, there are several issues which must be solved in this case, as discussed below.
The document MEF 6.1 referred to above describes the measurement of the loss of synthetic OAM frames, but not the loss of service frames. With synthetic loss measurement the real loss of service frames can only be estimated: precise measurement is not possible.
Other existing documents such as WO 2008/050929 define a framework but provide no solution to any of the technical issues. The main proposal of WO 2008/050929 is that lost frames should be measured as the difference between incoming and outgoing frames. However, there is no solution proposed for problems arising when one wants to measure the loss for multicast traffic exactly. Such problems include:                different address for service and OAM frames;        consequences of using MMRP or IGMP snooping; and        handling of dynamic changes in the registrations for a service.        
OAM frames used for measurement typically contain counters containing a value obtained from corresponding counters maintained in the network nodes. For example, a “sent frames” counter maintained in the source node is read out and copied into the loss measurement OAM frame. The OAM frame thus carries a record of the number of service frames sent by the source node for a particular service. When the receiving node receives the OAM frame, it compares the counter with the number of service frames actually received. The difference between the two numbers should provide a measurement of the number of lost frames.
OAM destination addresses defined in ITU-T Rec. Y.1731 are not the same as the service multicast address. This means that there is a chance of reordering or that the service and OAM frames are forwarded on a different path. As a result of this, service frames sent after the counter readout may arrive before the loss measurement OAM frame containing the counter value, or service frames sent before the counter readout may arrive before the loss measurement OAM frame. This causes inaccuracy in the loss measurement.
Furthermore, unless IGMP snooping, MMRP or a similar method is used as shown in FIG. 3, multicast service frames are transmitted to all bridges in the network, regardless of whether the bridge is subscribed for the service, as illustrated in FIG. 2. Both cases raise issues.
If IGMP snooping or MMRP is not used, then all multicast frames reach all nodes. If a receiving node subscribes to the multicast service during a measurement period, the counter in the first loss measurement OAM frame received by the receiving node will account for some service frames sent before the receiving node subscribed to the service. These service frames will never be received by the receiving node and the first measurement after subscription will inevitably be inaccurate.
MMRP and IGMP snooping set the forwarding in intermediate nodes according to the subscription to a multicast service, and thus eliminate the forwarding of multicast service frames to unsubscribed nodes. They manipulate the forwarding for the service multicast destination address but do not contain any explicit information on the subscribed nodes.
If IGMP snooping or MMRP is used, even though no service frames reach unsubscribed nodes, the loss measurement OAM frames may still reach an unsubscribed node if the service and OAM destination addresses are different. In such a situation the loss measurement is very inaccurate at an unsubscribed node: the OAM frames contain the “sent frames” counter of the source, which includes all multicast frames sent out by the source for a particular service, and has the same value irrespective of the subscription by receiving nodes. If the receiving node is not subscribed it will never receive any of the corresponding service frames, and this results in a huge false loss value in the measurements. In other words, the filtering of service frames but not OAM frames due to MMRP or IGMP results in a continuous false positive loss when a receiving node is not subscribed. The first loss measurement immediately after subscription will also be inaccurate in just the same way as if MMRP or IGMP snooping is not deployed.
In addition, loss and delay measurement frames defined in ITU-T Rec. Y.1731 do not include an additional reference to the relationship for which the measurement is made. This is not a problem for point to point transmissions. However, it is a problem for multicast systems, where address measurements for each multicast are desired.
There is also a problem with reply frames under previously proposed systems. The loss and delay measurement reply frames defined in ITU-T Rec. Y.1731 are addressed to the unicast address of the root (source node), and are therefore able to measure leaf to root (destination to source) unicast point-to-point performance. They also contain information for the root about the root to leaf direction, which could be a point-to-multipoint multicast relation without extensions. Therefore multicast measurement reply frames containing unicast backward measurement information may result in confusion or contain redundant information compared to bidirectional unicast measurements.